With the emergence of new technologies for mobile telephony, packet-based communication solutions using Internet Protocol (IP) have been developed to support the usage of multimedia services, while different mobile and fixed user terminals with new functionalities for multimedia communication are emerging on the market. Services are also constantly being developed for terminal users to increase the field of usage and enhance the experience when generally consuming communication services.
An IP Multimedia Subsystem (IMS) network can be used for enabling multimedia services and other communication services by initiating and controlling sessions for user terminals connected to various different access networks. The sessions are handled by specific session control nodes in the IMS network, including those referred to as Call Session Control Function (CSCF) nodes.
A signaling protocol Session Initiation Protocol (SIP) is used for multimedia sessions in IMS networks and other communication services networks.
Various identities may be associated with IMS, such as private user identities, IP Multimedia Private Identity (IMPI) and public user identities, IP Multimedia Public Identity (IMPU). Both IMPI and IMPU are Uniform Resource Identifiers (URIs) that can be digits (a Tel URI, like tel:+1-555-123-4567) or alphanumeric identifiers (a SIP URI, like sip:john.doe@example.com). IMS identities are stored in a subscriber database, hereinafter referred to as a Home Subscriber Server (HSS) together with subscriber service profiles, service triggers and other information.
The IMPI is a unique permanently allocated global identity assigned by the home network operator, and is used, for example, for Registration, Authorization, Administration, and Accounting purposes. Every IMS user shall have one or more IMPI.
The IMPU is used by any user for requesting communications with other users. The IMPU can be published (e.g. in phone books, web pages, business cards). There can be multiple IMPU per IMPI. The IMPU can also be shared between several terminals, so that several terminals can be reached with the same identity (for example, a single phone-number for an entire family).
IMPUs may be stored in the HSS as Wildcarded Public User Identities (wIMPUs). The wIMPU represents a collection of IMPUs that share the same service profile and are included in the same Implicit Registration Set (IRS). An IRS is a group of IMPUs that are registered via a single registration request. When one of the IMPUs within the set is registered, all IMPUs associated with the IRS are registered at the same time. wIMPUs include a regular expression (reg exp) that defines the identities that should be matched and handled as defined for the wIMPU.
A Public Service Identity (PSI) identifies a service, or a specific resource created for a service on an Application Server (AS). The PSI is stored in the HSS either as a distinct PSI or as a wildcarded PSI (wPSI). The distinct PSI contains the PSI that is used in routing, whilst the wPSI represents a collection of PSIs. The format of the wPSI is the same as for the wIMPU.
The handling of wildcarded identities was specified in the Third Generation Project Partnership (3GPP) Release 7 and 8 respectively, see for instance 3GPP Technical Specification (TS) 23.003. wIMPUs have been included in the standards to support Private Branch Exchanges (PBX) where thousands of numbers can be registered from one single identity. Implicit registration is not applicable as downloading thousands of implicit identities registered to the rest of the system is not an option (the message would be too long).
There has therefore been a need for the wIMPU which is associated with a group of IMPUs sharing the same service profile and requiring a single explicit registration to provide services to all the identities behind a PBX. The following conditions are applicable for the wIPMU:                All the identities within the range of a wIMPU will be handled by the same Serving CSCF (S-CSCF) in a situation of routing towards a core network or by the same PBX in a situation of routing between a User Equipment (UE) and the IMS network (Gm interface).        No individual service profile is provisioned anywhere in the network for the specific identities within a wIMPU.        
However, an individual service profile may be provisioned for a distinct identity within the range of the wIMPU. A distinct identity is provisioned, i.e. in the HSS, while a specific identity is not provisioned.
The standard document 3GPP TS 29.228 V9.3.0 (September 2010) specifies the interactions between the HSS and the CSCF nodes, referred to as the Cx interface.
Since a distinct public identity falling into the range of a wildcarded public identity can have a different service profile than the wildcarded public identity, 3GPP TS 29.228 has specified a behaviour to ensure application of a correct service profile. The service profile is included in a user profile. The term user profile will hereinafter be used. (The user profile may contain several service profiles.)
Assume that a wIMPU is registered in an S-CSCF so that all terminating calls destined towards any IMPU, within the range of the wIMPU, is routed to the IP address of the PBX. Further assume that a terminating request is received at an Interrogating CSCF (I-CSCF) for an IMPU within the range of the wIMPU. Let us assume that the IMPU is a specific, non-provisioned IMPU. Upon receiving the terminating request, the I-CSCF performs, according to standard procedures, a Cx-Location-Query towards the HSS and receives the S-CSCF name together with an indication that the IMPU matches a wIMPU. Further, the I-CSCF forwards the request to the S-CSCF and also includes the wIMPU. The S-CSCF shall then, according to 3GPP TS 29.228, use the received wIMPU to fetch the user profile. If we instead assume that the IMPU is a distinct, provisioned IMPU, then the I-CSCF will be informed by the HSS that the IMPU is distinct, and will forward the request to the S-CSCF, without including the wIMPU. The S-CSCF shall then, according to 3GPP TS 29.228, use the received distinct identity to fetch the user profile. In this way it is assured that a correct user profile is applied also in the case when a distinct identity, within the range of a wildcarded identity, has a different user profile than the wildcarded identity.
However, the inventors have realised that in a non homogeneous network, when some entities do support optional functionality or protocol enhancements and other entities do not, the above described behaviour may not be followed. The SIP stack in the I-CSCF may not support a P-Profile-Key (PPK) header, which is supposed to carry the wildcarded public identity from the I-CSCF to the S-CSCF. In 3GPP standard documents before Release 10, the PPK header is optional, which implies that the S-CSCF may, incorrectly, not receive the wildcarded identity in situations when the wildcarded identity should have been received. If the S-CSCF does not receive the wildcarded identity in such situations, the HSS may de-register a registered wildcarded public user identity, resulting in terminating calls not being forwarded to the contact address of the wildcarded public user identity. There is therefore a need for solutions that provides for correct handling of wildcarded identities also in non homogeneous networks.